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Summary : This paper presents a system (PHENARETE) which understands and 
improves incompletely defined LISP programs, such as those written by 
students beginning to program in LISP. This system takes, as input, the 
program without any additional information. In order to understand the 
program, the system meta-evaluates it, using a library of pragmatic ruies, 
describing the construction and correction of general program constructs, 
and a set of specialists, describing the syntax and semantics of the 
standard LISP functions. The system can use its understanding of the 
program to detect errors in it, to eliminate them and, eventually, to 
justify its proposed modifications. This paper gives a brief survey of 
the working of the system, emphasizing some commented examples. 


Introduct ion 


Much effort is spent on the development of tools to help programmers in 
constructing, debugging and verifying programs. From simple editors and - 
trace-packages, the trend is towards more and more sophisticated automatic 
programmers  [3,81, auotomatic debuggers  [15,17,1] automatic assistants 
[14], automatic verifiers [11,5] or even the construction of new - 
semantically more firmly based - programming languages (PASCAL, ALPHARD). 


Most of these tools exhibit some weaknesses such as 


- they impose too many constraints on the intuitions of the programmer 
(cf [6]), 


they work only on a very Limited subset of possible programs (cf 
EL, 1515, 


they work only on correct programs (cf [2:1112 


Our aim in the design of our program understanding system was four-fold : 


-l- we wanted to have a System which makes explicit the know ledge 
involved in constructing and debugging programs; 
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-2- we wanted our system not to verify the correctness of programs but 
their consistancy 


-3- we wanted the system to provide hings for improving and correcting 
programs and 


-4- we wanted a practical, useful and running system. 


Thereupon we have built a program understanding system able to 
automatically correct and improve programs. This system, PHENARETE, 
assists beginning programmers during the writing and debugging of their 
programs. 


Programming errors 


The construction of a computer program can be divided into different 
steps : first, the programmer has to have a somewnat precise 
conceptualisation of the activity he disires the computer to perform. As 
quoted by Model [13], this conceptualisation doesn’t just restrain at the 
Level of overt input/output behaviour, but includes the projected programs 
manipulation of its internal data structures. Second, the programmer has 
to conceive a method by uhich the intended activity may be performed. 
Third, he has to express this method in terms of a programming Language 
and, fourth, he has to communicate the program to the computer. 


This process induces 5 major types of programming errors, related to these 
different steps : lexical, syntactic, semantic,  teleological and 
conceptual errors. 


Lexical errors are probably the most frequent - and more easily debuggable 
- errors. They are mainly misspellings or typographical mistakes, and are 
detectable at the word-level. They refer - in classical compilers - to 
the lexical analyser or scanner. 


Every language has rules governing the allowed forms of program 
statements. We call deviations of these rules syntactic errors. 


These first two kinds of errors, normally detected during the reading of 
the program (compilation phase), are - in this paper - invariably called 
surface errors or informalities. 


Another kind of errors is that - even uhen the syntactic form is correct - 
its meaning may be unclear, contradictory or invalid. Examples of this 
kind of errors are "division by zero", an attempt to multiply a number by 
a string or a call of a function which has no definition. We call such 
errors semantic errors. They are normally detected during the run-time of 
the program. l 


New algorithmic languages, such as PASCAL, MESA or ADA, try to detect 
semantic errors at the semantic level through "strong compile-time 
cnecking of data types and program interfaces". But even when they are 
detected by syntactic checking, the sources of such errors lie at the 
semantic level. 

Let us note that such compile-time checking is rather Limited, since even 
such a simple error as division by zero escapes the checking if the 
divisor isn’t just a constant or a variable, but an expressicn whose value 
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LS computed at run-time and the expression equals zero only sometimes. 


The fourth class of errors we can distinguish, are teleological errors, 
which occur when the program does something, but not what uas intended. 
These errors refer to problems in the scope of the programmers’? precise 
specification of the computational scheme or algorithm. 


In our paper we call errors of the last tuo kinds deep errors or 
inconsistencies. 


A last kind of errors is met if the source of the problem is in the method 
or approach devised by the programmer to achieve the desired computational 
activity. These errors are called conceptual errors. 


Cur system, PHENARETE, analyses the text of a program and, when it detects 
informalities or inconsistencies, it constructs and proposes possible 
corrections or improvements. These modified versions of the program, 
constitute for the novice programmer, a crucial component of his 
apprenticeship : basing on examples the process of improving and 
correcting imperfect programs, and basing on models the process of 
inventing future programs. 


The originality of the system resides 1) in its ability not only to detect 
low-order errors - a standard in todays compilers - but also middle- and 
even higher order errors (i.e. semantic and some teleological errors), 
and 2) in its attempt to use the knowledge necessary to detect errors, 
also to construct possible corrections. 


Dverview of the system 


The system takes as input the draft version of a LISP program and.delivers 
as result of its treatment one or more versions of the same program, 
corrected and improved.  PHENARETE proceeds in several steps (cf fig. 
1): first a preliminary analysis of the text of the program is per formed 
in order to detect and correct surface errors. By surface errors we mean 
errors detectable by local anlysis : simple lexical errors such as 
misspellings or parenthesis errors as well as syntactic ones such as 
errors concerning the wrong number of arguments in function calls. During 
this first analysis PHENARETE collects information for the following 
steps. Whenever it meets the name of a function (standard or user defined 
LISP function) it automatically activates a specialist, associated with 
this function, by the process of data driven function invocation [16]. 
These specialists represent its knouledge about the use and the effects of 
the associated functions. 
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figure 1 


The result of the first analysis - a syntactically correct program - is 
then meta-evaluated to verify the programs weii-formsdness. We say that a 
program is well-formed if it doesn't contain obvious infinite loops, 
doesn't have useless statements (i.e. statements never executed) and if 
it doesn’t contradict the set of rules incorporated in PHENARETE. Every 
final version of the program our system delivers is a well-formed program. 


When PHENARETE detects some informalities or inconsistencies, it annotates 
the corresponding part of the program and sends the code and the 
annotation to the repair-module, a module designed to eliminate errors 
(uith the help of stereotyped programming knowledges). The system stops 
the analysis process when not finding any more possible improvements. 


Organisaticn of PHENARETE 


The system is based on four main concepts : . 

-1- During the analysis of a program, PHENARETE constructs a description - 
an internal representation - of the program in terms of cognitive 
atoms. These may be considered as the nodes of a network-Like 
representatton of the program. | 


Each cognitive atom is composed of a set of facets uhich represent its 
different aspects, about which questions can be asked, such as 


- what type is it ? 
~ what is its definition ? 
~ Cif it is a function) what is its domain ? 


The facets are filled in during the analysis process. 

le distinguish betueen three classes of cognitive atoms, those 
concerning variables, those concerning labels and those concerning 
functions. The facets are the same for every atom inside the same 
Class, but they differ significantly from one class to another. 

The representation of a cognitive atom is a set of attribute/value 


pairs, and the value V found under the attribute P of atom A is Simply 
the answer the expert A can give to question P. 


-2- A set of specialists, i.e. a set of procedural specifications of the 
Syntax and the operational semantics of the standard LISP functions, 
such as CAR, CDR, EQ, COND etc. l 
We distinguish between two different types of specialists : 

- those describing the syntax and 


- those describing the semantics 


of the associated functions. 


^ 
1 
3 
$ 
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example : specialist CAR for the syntax 


[CRR-1 (X) => 
v (& atom (CAR X) 
& type QO = LISTP) 


v (& S-expression (CAR X) 
& type (val (X)) = LISTP) 


modify X until CAR-1 OO = T] 


paraphrasing : 


CAR expects that its argument is 

- an atom 
and the type of the value of the argument is a list 

- a S-expression 
and the type of the value of that S-expression is a list 
(e.g. a function call) 

else 

CAR has to modify the argument until one of these tuo 
conditions is trus 


and the specialist CAR for the semantics 


(X (meta-eval X)) 
(type (val (X)) = 
(type (val O02 = 7 


-» hypothesize (X, type: LISTP) 
T -> complain (X, type : LISTP) 
action : if (exist (CAR X)) --> (CAR X) 
else (create (CAR, 20) --> (CAR X)] 


or in paraphrasing : 
CAR-N 


has an argument named X, uhich must be evaluated 
one must verify 
Lf 
the type of value of the argument is a list, all is ok 
else 
Lf the type of value of the argument isn't known, one has 
to create a hypothetical value of type LIST for X 
else | 
one has to call the repair-module to change the text of 


the program in such a way that the value of X becomes a 
List 
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the value of CAR is 
if 
there exists already a CAR of X, this CAR 
else 
one has to create a symbolic value for X, the CAR of which 
will be the desired value 


Note that the internal description constructed during the analysis of 
each user function is used to construct tuo neu such specialists for 
each user function. 


The specialists are the agents of the meta-evaluation and they- 
represent the systems Knowledge about the programming Language used. 


-3- An algorithm of me£a-evajuation [7] which helps the system to analyze 
each of the possible paths of the program. This algorithm is composed 
of tuo parts : | 


- a module to determine the symbolic values, i.e. since the 
meta-evaluation doesn't use concrete values in order to evaluate the 
program, it must deduce from the text of the program the type and 
the structure of the arguments of the different functions to 
evaluate. Thus our algorithm is rather different from those 
proposed in [10, 12] which receive the symbolic values as input. 


- an evaluation module, i.e. a module able to evaluate functions on 
these symbolic arguments. 


With this algorithm one unique execution is representative for every 
particular execution [12]. 


-4- A set of pragmatic rules describing general program constructs and 
stereotyped methods to repair inconsistencies. These rules formalize 
and express explicitly the knowledge activated by every programmer 
when he ts reading a program. 


We do not use rules concerning the task domain of the programs : our 
intention was to build a system which does not ask for any additional 
information, i.e. which works only with the text of the program to be 
analyzed, so that the programmer is not obliged to accompany the 
programs by comments, asserttons or other specifications. The system 
Should work - without any additional information - in any possible 
task domain, numeric as well as symbolic. 


Our rules are very general and valid for every LISP program obeying to 
the following restrictions : 


- the names of variables, functions and labels are unique 
- each function call must be of the type "call by value" 


- the unique functional arguments permitted are explicit 
A-expressions. i; 
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We call this subset of LISP : “extended first order LISP". 


examples of pragmatic rules : 


rrr TT 
| rule of the dependence of a loop of the 
| predicate -» 
| 

given s € {loop} 


| 
| 
| 
| 
iexit-test of F} | 
| 
| 
| 
| 
| 


I 


| F 
| T 
| Y = {variable} so that 
| Vye¥ tel vct 
| then : VyeY val¢y) [F11 val’ (y) 

| ^ Val(y) = val’ Cy) 

| => val(F) = undefined 
———— ERROREM eee | 


in paraphrasing : 


Lf no variable of the exit-test of a loop is modified inside the 
Loop-body, then the loop is independent of the exit-test and either 
its execution is non-terminating or the loop will never be executed. 


A slight refinement of this rule is the following one : 


(2) 
rule of the structural well-formedness of loops => 


in a loop at least one of the variables used in the exit-test has 
to change its value inside the body of the loop, in such a way 
that its structure is simplified and converges towards the 
satisfaction of the exit-test. 


In order to use this rule, ue have implemented a small theorem prover 
which can prove the convergence by induction. As to the proof implied 
by this rule, the theorem-prover takes the. symbolic value of the 
varíables at the entry of the loop, and the modified symbolic values 
of the same variables after one meta-evaluation of the  loop-body and 
tries to prove the convergence towards the stop test. 


Let us give one last example of a pragmatic rule : 
(3) 
rule of the structure of recursive loops -»|. 


| 
| | 
F « {recursive function} | 
A = {call of F} so that AcF | 
S = {selection-clause} so that ScF | 
then : VacA 4seS acs | 

| 


^ 41Sc«S so that VacA acs 
Ce 


paraphrasing : 


| 
j 
i 
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in a recursive function, the recursive calls have to be inside a 
selection-clause, and at least one of the clauses must not contain a 
recursive call. | 


Presently ue have about a hundred rules incorporated in the System, 
dealing especially with iteration and recursion, the use of variables 
end list-processing. For almost every rule there exists a dual cna 
indicating how to modify the program in such a vay that the first one 
is satisfied. 


Soma commented exsnales 


To use PHENARETE, the user has to give the system only the text of the 
draft version of the program he wants to write, without any additional 
information like input/output assertions, comments, plans etc. The system 
will try to understand uhat the user uants to do and, if necessary, modify 
the text of the programm. 


To give some feeling hou the system works, let us examine some exampies in 
detail : 


Our first example is a (very) erroneous version of the well known REVERSE 
function. Here is the actual input to the system : 


* (P'(DE REV L1 L2 COND ULL LES A1 T RUE R1 ONS CRA A1 R22) 


PHENARETE uill first perform a preliminary analysis using only its 
syntactic knowledge, i.e. the specialists for the syntax and the spelling 
error corrector. The result of this first analysis is a syntactically 
correct LISP progam, a program accepted by any LISP interpreter or 
compiler. 


Here is the actual printout of PHENARETE at this point : 


ERROR: 

NAME --> C? ULL --> NULL? 
ERROR: 

NAME --> (€? L22 --> L2) 
ERROR: 

NAME --> C? 01 --> L1) 
ERROR: 

NAME --> (0? Al --> L1) 
ERROR: 

NAME --» (C? RUE --» REV) 
ERROR: 

NAME --> €? AL --> L1) 
ERROR: 

NAME --> C? ONS --> CONS) 
ERROR 

NAME --> C? CRA --> CAR) 
ERROR 

NAME --> (? A1 --> L1) 
ERROR 


NAME --> (? AB --» L2) 
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SURFACES IMPROVEMENTS : 


(DE REY (L1 L2) 
(CON 


Cf &RzU L1 (CENS CORR L3) Lg33333 


These first improvements have eliminated all the syntactic errors. 
However, at least one semantic error remains s 


Neither Li nor LZ are modified in such a way that their values 
converge towards the stop test; even with a modification of Li in 
the recursive call, the recursion won't stop since the stop-test has 
as argument L2, a list which grows longer and longer on successive 
recursive calls (rule 2). 


During every analysis, our system collects useful information about the 
program, represented in the data-base which constitutes the internal 
description of the analyzed program. Figure 2 shows the state of the 
data-base after the first analysis of the function REV. 


~---- figure 2 somewhere here ---- 


data-base after the first analysis 


figure 2 
The knowledge represented in fig. 2 can be paraphrased as follows : 


After the first analysis PHENARETE knows that REV is a recursive 
function, with tuo arguments. The first argument is called L1, which 
the system doesn't know the value of, but knows it has to be a list, 
At the recursive call of REV, the first argument is not modified. 


The second argument is called L2. PHENARETE doesn't know its value 
either. It too has to be a List. At the recursive call L2 takes the 
value of the expression (CONS (CAR L1) L2). 


As for the errors detected up to that point, most standard scanners detect 
this kind of errors, and some compilers even handle this kind of 
corrections (PL/C or CORO. 


For the further improvements, the system proceeds to a meta-evaluation of 
the current version, using as symbolic value of the arguments just the 
knowledge that they have to be lists. If further specification about the 
values is needed, PHENARETE constructs them dynamically. 


In this example, the system has - corresponding to the tuo clauses of the 
selection (COND) - to develop tuo paths, one supposing the predicate (NULL 
L2) satisfied, one supposing it falsified. 


Note that one of the main differences between standard evaluation and 
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meta-evaluation is that the knowledge derived during the meta-evaluation 
of one of the possible paths can be used during the meta-evaluation of 
every other path. 


After one meta-evaluation of the function REY, PHENARETE has constructed 
en evaluation tree of the form : 


o REV List-Li List-L2 
| 


o COND 
/ 
L2-0 / Li=Cal an) 
/ L2-(bl ... bn) 
/ 
O o 
result« 1 REV (al ... an) 
(CONS al (bl ... bn?) 


As noted above, the meta-evaluation stops, when it reaches a point where 
no further continuation is possible (the case of the Left branch) or when 
it reaches a point where control has already passed by (which will be the 
case later on, during the meta-evaluation of the right branch of the 
tree). 


When the system meets a recursive call or an iteration, it carries on the © 
evaluation just as in normal execution. Here the continuation of the 
right branch of the tree forces the system to falsifie the first predicate 
of REV, since the symbolic value of L2 is a CONS-expression which can’t 
equal NIL (the empty list). So ue find : 


o REV List-L1 list-L2 
| 
o COND 
/ 
L220 / Li=Cal ... am 
/ L2-bl ... bn) 
/ 
O o 
result=L1 REV Cal ... am 
(CONS al (bl ... b2)) 


COND 


| 
o 
| 
| Ll=(al ... an) 

| L2=(CONS al 

| (pl ... bm) 
fe) 

V 


(al ... am 
(CONS ai 
(CONS al 
(bl ... bn))) 


RE 


At this point PHENARETE has to stop the meta-evaluation : all terminal 
leaves are either end-points of the program or points already visited 
during the meta-evaluation. 


http;//www.artinfo-musinfo.org Rapport ATP 4273, octobre 1980, page 63 / 124 


oe Stereotyped Program Debugging : an Aid for Novice Programmers 


Application of the pragmatic rules, especially those concerning recursion, 
indicates that the program won’t stop, since the modificatian of the 
arguments isn’t in such a way that they converge towards satisfaction of 
the exit-test (rule 2) : the exit-test checks if L2 is a empty list, but 
L2 grows longer during the successive recursive calls. The demonstration 
here is straightforward, but we easily realize that the power of the 
system depends crucially on the power of the incorporated theorem prover. 


Each rule is combined with an ordered set of advices as to "hou to 
correct" the non-satisfaction of the rule. The advices of rule 2 say that 
in order to correct ihe code, we have to suppose that 


—-1- there is an error in the stop test or 
-2- there is a missing stop test or 
-3- there is an error in the recursive call 


The pragmatic rules as well as the advices (whicn are just pragmatic rules 
of correction) are hierarchically organized, from the general to the 
concrete, i.e. the application of one rule may result in the application 
of a lot of other rules. | 


In this case the first advice PHENARETE finds applicable is the third one. 
Here is another point of the system which deserves some critics : 
PHENARETE supposes that at least one of the arguments has to simplify its 
structure in the successive calls. If this isn't the case, and the system 
doesn't find an error, all is ok, but otheruise it forces a 
simplification. Here the simplification is forced by the use of the CAR 
of L1: PHENARETE assumes the user wants to work with successive elements 
of L1, which makes it introduce the modified recursive calt 


(REU (COR LICCONS CCAR L1) Le)) 


No doubt, if the programmer didn’t want that, eventually he won't 
understand any more the correction of PHENARETE. But, in constructing the 
system we wanted the programmer not to be obliged to give asssertions or 
comments, so we have no means to know anything about the intentions of the 
programmer (except what is explicitly stated in the code), and the 
proposed corrections may differ significantly of those used by an 
experienced programmer knowing the intentions. 


But, to justify our approach, before beginning to write the system, ue 
have systematically studied, during one year, the programs uritten by our 
students. The corrections PHENARETE proposes, are those corresponding to 
the statistically most current errors. Qn the other hand, we think a 
program uhich stops and delivers a result different from the intended one 
is easier to debug than a program entering in an infinite Loop.  PHENARETE 
just corrects progams in such a way that they don't abort and stop 
delivering a result, uhen executed. 


After each modification, the system re-meta-evaluates the program, to 
check if any error remains. 


In our example PHENARETE can not disambiguate this function - it does not 
know anything of the intentions of the programmer - so it gives two 
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different propositions : 
FROFGSITICA 1 
(DE REV (L1 L2) 
CCON 

CCNULL L2) L1) 

CCNULL L1) L8) 

CT (REU (CIR L1) COONS CCAR L1) £23333) 

AT LEAST YOUR FUNCTION SEEMS OX. 

In this first proposition, PHENARETE supposed the given stop-test correct, 


but assumed that the user omitted a second stop-test in case the second 
argument is not NULL at the initial call of REV. 


PROPOSITICN 2 : 
(DE REV (L1 Le) 
CCOND 
CCNULL L1) L2) 
(T (HEU (CDR L1) (CONS CCAR L1) £23333) 
AT LESST YOUR FUNCTION SEEMS OX. 

In this second proposition, PHENARETE supposed that the user inadvertently 
inverted the arguments of the stop-test, so it inverts the two arguments 
L1 and L2. 
PHENARETE secures that the tuo corrected versions of the initial 
draft-program (which are not identical) will stop and deliver a result 


when executed. 


The data-base after the completion of the analysis of REV is represented 
in figure 3 (only for the second version) : 


figure 3 here somewhere 


data-base after the analysis 
figure 3 


Two sources of information are available after the complete analysis of a 
program : 


- the program as an executable algorithm 
- the description of the program in the data-base 
This data-base doesn't describe 'how' or 'uhat' the program computes, but 


gives valuable indications on the conditions which have to be verified if 
the program is activated and on those which are verified after its 
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This description is used to construct new specialists, in order not to 
reanalyze the function if it is called by another one. 


Here are the tuo specialists : 


specialist REV for the syntax 


[REV-1 (O0 => 
& ( 


atom (CAR X) 

& type (CAR X) = LISTP) 
S-expression (CAR 70 

& type (val (CAR X)) = LISTP)) 
atom (CADR X) B 
type (CADR XO = LISTP) 
S-expression (CADA X) 
type (val (CADR X)) = LISTP 


xX until REV-1 OO = T 


specialist REV for the semantics 


[REV-N => 


arg : (X Y (meta-eval QO meta-eval C¥))) 
test : (type OO = LISTP). 
-> (type (Y) = LISTP) -> 
(type CD = ?) 
-» hypothesize (Y, type:LISTP) 
T -» complain (Y, type:LISTP) 
(type (X) = ? 
-> hypothesize (X, type:LISTP) 
| go test qu 
T -» complain (X, type:LISTP) 
Ms test 
action: => {LISTP, execute-symb (REV X Y¥)}] 


As can be easily verified, the specialists are just algorithmic 
transcriptions of the data-base. 


Now, when PHENARETE meets, during the analysis of another program, a call 
to the REV-function, it hasn't to reanalyze the body of the function, but 
it can use the specialists of REV in the same manner it uses the 
specialists of the standard function. 


Üur second example is an extremely "simplified" version of the equally 
well-known FACTORIAL function. Here it is: 
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et re tf Ps i A me 


? (GE FACT N TIMES N PROT ND 


As in the previous example, PHENARETE will first translate this 
unparenthesized expression into an well parenthesized one : 


SURFACE IMPROVEMENTS : 
(DE FACT (CN) (TIMES N ("ECT 0023 


This first proposition is a syntactically correct program, but 
semantically it presents some difficulties : 


-1 at the recursive call, N is not modified (rule 1). 


-2 there is no stop-test at all (rule 3), so there are tuo (1) reasons 
to make the recursion infinite.. 


Remember that PHENARETE doesn’t know the intentions of the programmer, so 
it must detect these errors without any additional information : all that 
can be used in the further analysis are the semantic specialists and the 
pragmatic rules. So let us look at its versions : 


PROPOSITION: 


(BE FACT CN) CCOND 
CILE N OD) 1) 
(T (TIMES N CFACT CEUST R232200) 


AT LEAST YOUR FUNCTION SEEMS OX. 


This corrected version is actually a correct version of the 
factorial-program. The performance illustrates well the pertinance of the 
pragmatic rules, knowing that the system works completely automatically 
without asking any questions to the user and without any information about 
the supposed intention. 


One last example : 


? (DE ADDIT M N (CCCZEROP AD PD) 
(T (ADDIT SUB1 M ADDI ND) 


SURFACE IMPROVEMENTS : 
(GE ADDIT CH N) 
(COND 
CCZERUP ND M) 
(T (ADDIT CSUB1 M (ADDI 03223) 
PROPOSITION: 
(DE ADDIT M ND 


CCOND 
CCZEROP ND PD 
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(CLE HO) N) | 
(T ADDIT £(SU31 PD (ARDI 0332) 


AT LEAST YOUR FUNCTION SEMS Cx. 


The difference between this example and the previous one consists mainly 
in the constructed return value of the function. In the FACT example, the 
value returned was just the neutral element of the operation applied to 
the result of FACT (e.g. TIMES), in this example a value is computed 
during the recursion, thus this newly computed value will be tne result of 
the function. 


Donclusion 


We have presented a running system which corrects incorrect student 
programs in some stereotyped way. 


There are tuo major shortcomings we would like to mention : 


-1- Our system relies heavily upon a (still very small)  theorem-prover, 
and - related to it - the internal representation of the abstract 
data-structures. These two modules are currently much too limited to 
apply the system to real user progams (and not only to small student 
programs). But looking at most other systems of meta-evaiuation  [10, 
12 for example] it is one of the first systems carrying on the 
meta-evaluation not only on numeric programs but on symbolic ones, 
where no algebraic theory yet exists. 


We think we vill use for the next version of the system the abstract 
List-representation proposed by Goossens [7]. 


-2- The total absence of any mean to communicate to the system the 
intentions of the programmer constitutes - as soon as one leaves more 
or less toy programs - a severe handicap. Presently we are 
investigating possibilities to encompass this shortcoming. Different 
approaches are possible and we don’t know yet which one to choose : 
either allou comments (but uhat should we do if there are errors in 
the comments?) or oblige the programmers to give some input/output 
examples, which would permit to use real and symbolic values (but same 
question as above). 


We are presently implementing PHENARETE as a standard VLISP [4, 9] error 
routine, L.e. as soon as during the execution of a program an error 
occurs, we trap it and apply the system to the program which caused the 
error. This will eliminate the - always existing - possibility that the 
program modifies a correct - but for tt unintelligible - program. 


A word about LISP : the only reason why ve have choosen LISP is the 
isomorphism between external and internal representations, and because our 
students learn LISP as first programming language. The algorithms and 
rules used are very general and not LISP-specific. An implementation of 
PHENARETE for an algorithmic language, say Pascal for example, seems 
Straightforward : the system would even have less work in determinig the 
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symbolic values because of the typed declaration of all identifiers. 


The system is running on FPDP-10, uses about 25k word memory, is 
implemented in VLISP [4,9], and is used by about 600 students in our 
university. 


A more detailed description may be found in [18]. 
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